Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarLint
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarCloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube

Secrets
ABAP
Ansible
Apex
AzureResourceManager
C
C#
C++
CloudFormation
COBOL
CSS
Dart
Docker
Flex
Go
HTML
Java
JavaScript
JCL
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Scala
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML

COBOL static code analysis

Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your COBOL code

Tags

Impact

Clean code attribute

Section names should be unique within a program
Code Smell
DDL statements should not be used
Code Smell
"PERFORM" calls should not be recursive
Code Smell
"COPY SUPPRESS" should not be used
Code Smell
"LIKE" clauses should not be used without wildcards
Code Smell
Open files should be closed explicitly
Code Smell
Copybooks should not contain keywords relating to the nature or structure of a program
Code Smell
Data used in a "LINKAGE" should be defined in a COPYBOOK
Code Smell
"EVALUATE" structures should end with "WHEN OTHERS" clauses
Code Smell
Cyclomatic Complexity of sections should not be too high
Code Smell
Cyclomatic Complexity of paragraphs should not be too high
Code Smell
Cursors should not be opened inside loops
Code Smell
Cursors should not be declared inside loops
Code Smell
Cursors should not be closed inside loops
Code Smell
String literals should not be duplicated
Code Smell
Copybooks should be used to share data structures, not procedural logic
Code Smell
"OCCURS DEPENDING ON" should be used with a minimum value
Code Smell
Unused condition names should be removed
Code Smell
"BINARY" variables should be used to declare variable-length table sizes
Code Smell
Binary variables should be used for table subscript access
Code Smell
Conditional variables should not be compared with literals
Code Smell
Variables of different numeric formats should not be compared
Code Smell
Conditions should not use too many distinct data items
Code Smell
Boolean expressions should not be gratuitous
Code Smell
Two branches in a conditional structure should not have exactly the same implementation
Code Smell
SQL "LIKE" clauses should not start with wildcard characters
Code Smell
Column names should be used in a SQL "ORDER BY" clause
Code Smell
SQL statements should not join too many tables
Code Smell
Declared files should be used
Code Smell
"SORT" should not be used
Code Smell
"MERGE" should not be used
Code Smell
Columns to be read with a "SELECT" statement should be clearly defined
Code Smell
Ending words should be aligned with what they close
Code Smell
"PERFORM" calls should not be nested too deeply
Code Smell
Sections should be documented
Code Smell
Sections should not be empty
Code Smell
Nested SQL "SELECT" statements should not be used
Code Smell
Sections of code should not be commented out
Code Smell
SQL EXISTS subqueries should not be used
Code Smell
Track uses of "FIXME" tags
Code Smell
Redundant pairs of parentheses should be removed
Code Smell
Collapsible "IF" statements should be merged
Code Smell
Unused "TABLE" declarations should be removed
Code Smell
Binary search should be used for large tables
Code Smell
Arithmetic expressions and scalar functions should not be used in "WHERE" conditions
Code Smell
"OCCURS 1" should not be used on data items
Code Smell
Program names should comply with a naming convention
Code Smell
Track uses of "TODO" tags
Code Smell
"UPDATE" and "DELETE" statements should not impact multiple rows
Code Smell
"ALTER" should not be used
Code Smell
"LOCK TABLE" should not be used
Code Smell
Track lack of copyright and license headers
Code Smell
"GO TO DEPENDING ON" should not be used
Code Smell
"0 RECORDS" should be specified for "BLOCK CONTAINS"
Code Smell
"INSERT" statements should explicitly list the columns to be set
Code Smell
"PERFORM ... THRU ..." should not be used
Code Smell
Either "RESP" or "NOHANDLE" should be used with CICS commands
Code Smell
The return codes of CICS commands with "RESP" or "NOHANDLE" conditions should be tested
Code Smell
"COMMAREA" length should be specified in "CICS Link" and "CICS Xctl" commands
Code Smell
"EVALUATE ... WHEN" statements should not contain conditional logic
Code Smell
"FILE STATUS" should be checked after IO operations when it is available
Code Smell
"SECTION" should not be used in a "PROCEDURE DIVISION"
Code Smell
"REDEFINES" should not be used
Code Smell
The number of "PERFORM" statements in a procedure, section, or paragraph should be limited
Code Smell
Control flow statements should not be nested too deeply
Code Smell
"GO TO" should not be used
Code Smell
The cyclomatic complexity of a program should not be too high
Code Smell
Limited dependence should be placed on operator precedence
Code Smell
"OCCURS DEPENDING ON" should not be used
Code Smell
SQL statements should not use "CAST(... AS CHAR/VARCHAR)"
Code Smell
Condition names should be named for their conditional variables
Code Smell
Math should only be performed on computational variables
Code Smell
"CALL" programs should be specified dynamically
Code Smell
"SELECT" statements should not lead to full table scans
Code Smell
Track parsing failures
Code Smell
Files should not contain too many sections
Code Smell
SQL "OR" clauses testing equality on the same identifier should be replaced by an "IN" clause
Code Smell
A SQL "BETWEEN" clause should be used instead of "X>=Y AND X<=Z"
Code Smell
"FOR READ ONLY" or "FOR UPDATE" should be specified for DB2 cursors
Code Smell
"READ" statements should have an "AT END" or an "INVALID KEY" clause if "FILE-STATUS" is not defined
Code Smell
The number of subprograms called in a program should be limited
Code Smell
Files should not contain too many paragraphs
Code Smell
The number of COPY directives in a program should be limited
Code Smell
Packed numeric fields should be defined with odd length
Code Smell
The last paragraph of a "PERFORM THRU" should only contain an "EXIT" statement
Code Smell
Paragraphs should follow a naming convention
Code Smell
Procedures used in "PERFORM ... THRU ..." should share a naming convention
Code Smell
Paragraphs should be documented
Code Smell
New types should be defined in copybooks
Code Smell
"WHERE" clauses should not contain too many lines of code
Code Smell
"UNION" should not be used in "SELECT" statements
Code Smell
"PERFORM SECTION" should not be used
Code Smell
"PERFORM PARAGRAPH" should not be used
Code Smell
Paragraphs should not be used
Code Smell
"OPEN" should not be used inside a loop
Code Smell
"NEXT SENTENCE" should not be used
Code Smell
"GROUP BY" should not be used in SQL "SELECT" statements
Code Smell
"EXAMINE" should not be used
Code Smell
"DISTINCT" should not be used in SQL "SELECT" statements
Code Smell
The "COMPUTATIONAL" data value clause should not be used
Code Smell
Track uses of SQL
Code Smell
The OS/VS "TRANSFORM" statement should not be used
Code Smell
The OS/VS "ON" statement should not be used
Code Smell
Programs should not have too many lines of code
Code Smell
The "LIKE" operator should be used very carefully in SQL "WHERE" condition
Code Smell
Sections and paragraphs should not perform more than one SQL operation
Code Smell
Unused sections should be removed
Code Smell
Sections should not have too many lines of code
Code Smell
Track uses of "NOSONAR" comments
Code Smell
Unused paragraphs should be removed
Code Smell
Unused data item blocks should be removed
Code Smell
Paragraphs should not have too many lines of code
Code Smell
Paragraphs should not be empty
Code Smell
Modules should not have too many lines of code
Code Smell
Closable statements with nested statements should be closed
Code Smell
Track comments matching a regular expression
Code Smell
Statements should be on separate lines
Code Smell
Magic numbers should not be used
Code Smell
"SQLCODE" or "SQLSTATE" should be tested after each SQL statement
Code Smell
Default column values should not be set explicitly in inserts
Code Smell
Fetches should use all of the columns selected in their cursors
Code Smell
Programs should begin with titles
Code Smell
SQL "UPDATE" statements should not impact columns included in partitioning indexes
Code Smell
Obsolete keywords should not be used
Code Smell
Level 77 should not be used
Code Smell
SQL "WHERE" clauses should use ANSI standard operators
Code Smell
SQL tables should be joined with the "JOIN" keyword
Code Smell
Data items should never be accessed using more than one "OF" clause
Code Smell
Data item declarations should be aligned
Code Smell
"TO" keywords should be aligned in a sequence of "MOVE" statements
Code Smell
Logical files should follow a naming convention
Code Smell
First level data items should follow a naming convention
Code Smell
File-Codes should comply with a naming convention
Code Smell
File names should comply with a naming convention
Code Smell
"INITIALIZE" should not be used
Code Smell
Disallowed characters should not be used in identifiers
Code Smell
Sections should end with an empty paragraph
Code Smell
The OS/VS "NOTE" statement should not be used
Code Smell
"OS/VS EXHIBIT" should not be used
Code Smell
Paragraphs and statements should be indented consistently
Code Smell
"CURSORs" should not be declared inside procedure divisions
Code Smell
Tabulation characters should not be used
Code Smell
Track uses of forbidden statements
Code Smell
Track uses of disallowed modules
Code Smell

The number of "PERFORM" statements in a procedure, section, or paragraph should be limited

adaptability - focused

maintainability

Code Smell

CriticalSonarSource default severity
click to learn more

brain-overload

Why is this an issue?

The worst nightmare of every COBOL maintenance programmer is a program where you have to follow 12 concatenated PERFORM statements before you get to the actual processing. This is considered to be the GOTO-less version of spaghetti programming.

This situation can be avoided by having a mainline procedure at the beginning of the procedure division which concentrates all program control, and which reads like a map of the program. This mainline procedure should be free from detailed operations such as moving fields, calculations, I/O operations, and so on.

This rule helps ensure that most program control is concentrated in the mainline procedure (the first one in the program) by preventing the other procedures from having more than a predefined threshold of "PERFORM" statements.

Available In:

Catch issues on the fly,
in your IDE

Detect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

Enterprise
Edition

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Sonar helps developers write Clean Code.
Privacy Policy | Cookie Policy

In-IDE

SaaS

Self-Hosted